개요

The ability to collect data about programs' execution, modules' internal states, and the communication among components

관측가능성(Observability)은 프로그램 실행, 모듈의 내부 상태, 컴포넌트 간 통신에 대한 데이터를 수집하는 기능, 능력으로 정의된다.^[1]
[[#사견 - 관측가능성과 모니터링의 차이]]에서 짚었지만 이는 살짝 혼란을 줄 수 있는 정의인데, ability라고만 하면 주체가 누군지 확실하지 않기 때문이다.
관측가능성은 관리자가 잘 볼 수 있도록 필요한 메트릭과 각종 정보를 수집해서 내어주는 시스템의 기능이다.
그래서 이 개념은 모니터링과 대비되는 개념이 아니다.

관측가능성이란 용어는 꽤나 넓은 의미를 커버하는데, 다양한 데이터를 통해 각종 문제를 진단하고 원인 분석, 대응을 하는 일련의 작업과 툴까지도 총칭해버리기도 한다.

참고로 쿠버네티스를 줄여서 k8s라고 하듯이, 이 친구도 줄여서 o11s라고도 부른다.

배경

시스템의 구조는 장애 회복력, 고가용성 등을 위해 내부의 컴포넌트들 간 종속성을 줄이고 결합도를 느슨하게 하는 방향으로 발전하고 있다.
대표적인 예시가 MSA인데, 이러한 아키텍처는 소기의 목적을 분명하게 달성하는데 도움을 주지만 되려 내부 구조를 복잡하게 만들어 다양한 문제를 야기하기도 한다.
일단 분산된 거대한 시스템 내부에서 일어나는 상황을 제대로 알기 어렵다는 것이 핵심이다.
이로 인해 어떠한 문제가 발생해도 어디에서 문제가 발생한 것인지 추적하는데 시간이 오래 걸리고, 문제라고 생각해야 할 만한 상황 자체를 탐지하는 것조차 어려워지기도 한다.

이때 시스템의 내부 상태를 좀 더 가시적으로 만들어야 한다는 수요가 생겨났고, 자연스레 관측가능성이란 개념이 떠오르게 됐다.
현대의 운영 담론에서는 모든 고장이나 문제를 사전에 알 수 없고, 고정된 기준을 두고 파악할 수 없다는 것을 가정한다.
대신 시스템으로부터 최대한 다양한 방법으로, 다양한 지표를 수집하여 정제된 형태로 시각화하는 것을 목표로 시스템에 각종 설정을 한다.
이를 통해 가급적 발생한 문제를 빠르게 탐색하고, 아울러 발생할 수도 있는 문제들을 투명하고 직관적으로 볼 수 있게 환경을 구성하는 방향으로 나아가고 있는 것이다.

이렇게 관리자가 편하게 시스템으로부터 노출되는 외부 신호와 특성만을 통해서 내부 상태를 파악할 수 있도록 하는 시스템의 속성을 관측가능성이란 용어로 표현하기 시작했다.
관측가능성이란 개념이 나온 흐름은 이 정도로 요약할 수 있을 것 같다.

• 현대 시스템은 모든 문제를 사전에 알 수 없다.
• 그래서 관리자가 각종 지표가 드러나도록 능동적으로 세팅하는 과정이 필요하다.
  • 이를 통해 시스템의 내부 상태를 쉽게 파악하여 문제를 탐색하는 것을 용이하게 한다.
• 이렇게 세팅된 시스템은 관측 가능성을 가졌다고 표현한다.

고가용성은 명확하게 수식을 정의할 수 있는 지표이나, 관측 가능성은 수치화하기 어렵다.
사실 관리자, 개발자가 필요로 하는 각종 데이터들이 회사마다 환경마다 다를 수 있고, 구축하고 세팅한 정도를 나타낸다고 해서 그게 그렇게 의미가 있는 것도 아니다.
다만 비즈니스 개념을 얹어서 MTTR(Mean Time To Recovery)를 보완하며 간접적으로 정도를 표현하는 것은 가능하겠다.

측정 대상 - 시그널

시스템에 관측 가능성을 부여하기 위해 측정(telemetry)할 만한 데이터, 혹은 요소가 무엇이 있을까?
오픈텔레메트리에서는 이러한 데이터들을 신호(signal)라고 표현한다.
현대에는 수집할 신호를 크게 3가지로 분류하고 있다.

간단하게는 지피티가 이렇게 요약하는데, 잘 설명한 것 같다.^[2]

메트릭(Metric)

시스템의 특정 시간을 나타내는 수치값이다.
보통 통계(statistics)라고도 표현한다.
메모리 사용량, 초당 http 요청량, 데이터베이스 사이즈 등이 여기에 해당한다.

메트릭은 시각화하기에는 가장 용이한 시그널로, 그라파나 같은 것으로 이쁘게 볼 수 있게 세팅하곤 한다.

로그(Log)

자유롭게 생성되는 각종 텍스트 데이터를 말한다.
이 개념은 사실 굉장히 포괄적인데, 어떤 데이터를 담고 있는 흔적들이라고만 이해해도 무방하다.
이 데이터들은 그 자체로 사용하기 매우 어렵고 방대하다.
그래서 유의미한 로그만 따로 수집하거나, 정제하여 새로운 메트릭으로 만들어내는 등의 작업을 하는 것이 보통이다.

프로세스의 표준 출력, 디비 접속 기록 로그 파일 등이 전부 로그에 해당한다.

이벤트(Event)

나는 이벤트란 것도 로그의 일부라고 본다.
이벤트는 시스템에서 관리자가 지정한 유의미하게 발생한 사건을 일컫는다.

위에서 디비 접속 로그 같은 것이 관리 요소로서 중요하다면 이벤트로서 다뤄야 하는 것이다.
로그 중에서 면밀히 다루고, 동시에 다른 운영 요소로서 활용하고자 하는 로그들을 이벤트라고 표현한다.

트레이스(Trace)

트래픽, 혹은 프로세스 등의 어떤 실제나 논리적 작업의 흐름을 말한다.
분산 아키텍쳐에서는 하나의 프로세스가 모든 로직을 담당하지 않는 경우가 왕왕 있다.

가령 어떤 유저가 자신의 글을 확인하는 api를 요청했다고 해보자.
어떤 아키텍처에서는 먼저 게이트웨이에 이 요청이 온 후에 인증 서버, 인가 서버를 거쳐 유저의 요청을 허용할지 말지를 정한다.
이후에는 디비와 통신하는 서버로 요청이 들어가고, 샤딩된 디비에서는 어떤 디비에서 데이터를 가져올지 정한다.

이런 식의 일련의 트래픽이 발생할 때, 정확하게 어떤 프로세스가 어떤 요청을 받았는지 추적하고 이를 측정하는 것이 바로 trace이다.

트레이스는 복수의 주체가 있을 때 이들 간의 통신에 대한 정보를 보이는 것을 목표로 하기 때문에, 해당 통신이 이어지고 있다는 단서가 필요하다.
이 단서란 것을 조금 더 개념화시키면 흔히 문맥(context)이라고 표현하는데, 아무튼,
이렇게 작업의 흐름이 이어지는 것을 나타내는 단서를 span이라고 한다.
가령 http요청에 대해 헤더에 어떤 고유한 span 값을 붙이고 다음 서버로 전달하는 것이다.
그러면 스팬 데이터를 공유하는 모든 요청은 궁극적으로 하나의 요청이니 이를 추적하는 것이 가능해진다.
이렇게 현재 작업의 상태를 넘겨서 추적할 수 있게 만드는 과정을 문맥을 전파한다하여 context propagation이라고 부른다.

스팬(span)

트레이스, 즉 추적을 하기 위해서는 추적이 될 수 있도록 하는 단서가 필요하다.
이때 사용되는 것이 바로 span이다.^[3]
스팬은 서비스나 구성 요소 내에서 한 작업 단위를 나타내는 데이터 모음, 로그를 말한다.
이 값은 마치 연결 리스트마냥 이전 요청에서 들어온 id를 가진다던가 하는 방식으로 꼬리를 물고 추적할 수 있도록 돼있다.

{
  "name": "hello",
  "context": {
    "trace_id": "5b8aa5a2d2c872e8321cf37308d69df2",
    "span_id": "051581bf3cb55c13"
  },
  "parent_id": null,
  "start_time": "2022-04-29T18:52:58.114201Z",
  "end_time": "2022-04-29T18:52:58.114687Z",
  "events": [
    {
      "name": "Guten Tag!",
    }
  ]
}

이런 어떤 데이터가 있다 해보자.
context 부분에 trace_id와 span_id가 들어갔고, 그 아래에 parent_id는 없다.
이것을 부모가 없다하여 루트 스팬이라 부른다.

{
  "name": "hello-greetings",
  "context": {
    "trace_id": "5b8aa5a2d2c872e8321cf37308d69df2",
    "span_id": "5fb397be34d26b51"
  },
  "parent_id": "051581bf3cb55c13",
  "start_time": "2022-04-29T18:52:58.114304Z",
  "end_time": "2022-04-29T22:52:58.114561Z",
  "events": [
    {
      "name": "hey there!",
      "timestamp": "2022-04-29T18:52:58.114561Z",
    },
    {
      "name": "bye now!",
      "timestamp": "2022-04-29T18:52:58.114585Z",
    }
  ]
}

그렇다면 이 데이터는 어떤가?
위의 루트 스팬의 id를 parent_id로 가지고 있다.
이 데이터는 루트 스팬의 자식 스팬이 되는 것이다.
이렇게 스팬을 통해 각 데이터간의 위계를 명확하게 파악할 수 있다.
그러면서 전체는 하나의 trace_id를 가지므로, 궁극적으로는 하나로 봐야한다는 것을 확인할 수 있게 되는 것이다!

스팬의 형식

트레이싱을 지원하기 위한 다양한 도구들(Zipkin, Jaeger, 그리고 거의 De facto인 OpenTelemetry 등)이 있다.
원래 이들은 저마다의 문맥 형식을 가지고 있었다.
내가 아는 범주에서, HTTP 헤더로 붙는 스팬 규격 종류는 이렇다(다른 것들도 있긴 할 것이다).

• W3C - W3C에서 지정한 표준 형식으로, 오픈텔레메트리에서도 채택한 형식^[4]
  • traceparent - {버전}-{트레이스 id}-{부모 스팬 id}-
    • 벤더 중립적인 트레이스의 필수 정보
    • 전부 16진법으로 인코딩된다.
  • tracestate
    • 벤더 별, 운영 조직 별 커스텀할 수 있는 정보
    • 맘대로 키값쌍 때려박으면 된다.
• B3 - Zipkin에서 지정한 형식^[5]
  • 이전에 쓰던 방식은 각각 헤더가 있었다.
    • X-B3-Traceid, X-B3-Spanid, X-B3-Parentspanid, X-B3-Sampled, X-B3-Flags
  • 그나마 최신 방식은 하나의 헤더를 사용한다.
    • b3 : {트레이스 id}-{스팬 id}-{샘플링 비율}-
• Jaeger
  • uber-trace-id : {트레이스 id}:{스팬 id}:{부모 스팬 id}:

오픈텔레메트리가 굉장히 유명해지면서 기여도 활발하게 일어났고, 이에 따라 빠르게 발전했다.
워낙에 형식을 잘 정의하기도 해서 그런지, 점차 다른 툴들도 오텔의 형식을 지원하거나, 아예 오텔의 형식을 베이스로 하는 케이스가 늘어나고 있다.

사견 - 관측가능성과 모니터링의 차이

결론부터 말하자면, 이 차이를 구분 짓는 것이 크게 의미가 없다.
지금에 와서 내게는 관측가능성과 모니터링의 차이를 묻는 질문은 아래 질문 정도로 허무맹랑하게 느껴진다.
"책의 가격과 독서의 차이가 뭐에요?"

의미를 가질 수 있는 지점은 딱 하나, 모니터링을 잘만 해오던 운영자가 처음 관측가능성이란 개념을 알게 됐을 때 정도.

현 관측 가능성 담론의 문제점

나는 인터넷의 많은 글들을 보았지만, 대체로 관측 가능성에 대한 명쾌한 설명을 하는 글이 많이 없다고 느꼈다.
관측 가능성의 정의를 이야기하려는 듯이 말하면서 자연스레 관측 가능성의 특징과 속성에 대한 말을 하는 것 같달까, 본의 아니게 소크라테스가 되는 기분이었다.
내가 이해하는 방향이 맞을지는 모르겠으나, 관측 가능성이란 표현이 어디에 적용되는지를 먼저 알아야 이 개념을 헷갈리지 않게 머리에 박아둘 수 있다고 생각한다.
엄밀하게, 모니터링과 관측 가능성은 서로 대비시킬 수 있는 개념이 아니다.
내가 여태 본 관측 가능성의 정의라고 하는 글들의 정의에는 이런 것들이 있었다.
(허수아비 공격처럼 보일지라도, 싸움을 걸고 싶은 것도 아니고 내 이해를 명확히 하기 위해 시작된 거라 구태여 출처를 밝히진 않겠다.)

• 시스템을 계측해 메트릭을 수집하는 것.
• 시스템의 내부 상태를 파악하는 능력.
• 시스템 데이터를 분석하는 접근 방식.

그리고 이어지는 설명들은 대체로 기존과는 다르다고 어필하며 모니터링과 어떤 차이가 있는지를 나타내려고 했다.
사실 그 정도 설명을 보더라도 대충 관측 가능성이 어떤 의미를 가지고 있고 어떤 운영적 요소를 말하는지는 충분히 파악할 수 있다.
그렇지만 그래서 관측가능성이 뭔데? 라는 질문을 받을 때 나는 설명할 자신이 없었다.
위의 설명들이 혼선을 주는 부분은 누가 주체인가에 대한 것이다.
"관리자가" 시스템의 메트릭을 수집하고, 내부 상태를 파악하고, 분석하는 것이 관측 가능성인냥 해석될 수 있는 정의들이다.
이러면 분명히 관리자가 하는 행동인 모니터링과는 확실히 대비시킬 수 있는 말처럼 느껴진다.
그러나 관리자가 관측 가능성을 지녔다, 라는 표현이 말이 되는가?를 생각해보면 사실 어감이 상당히 이상해진다.
처음 이 용어를 접할 때 저런 설명들을 보며 Obersvability라는 표현이 잘못된 표현이라고까지 생각하게 됐다.

머리를 끙끙 싸매며 고민을 하다가 관점을 바꿔봐야 한다고 생각이 드는 순간 이치가 맞다고 느껴지는 부분이 있었다.

시스템 속성으로서의 관측 가능성

이 표현을 용어에 맞게 이해하는 접근 방식은 관측 가능성을 시스템의 속성으로서 이해하는 것이다.
관측 가능성은 시스템을 평가하는 하나의 척도로서, 이를 바탕으로 위의 정의들을 다시 표현하면 이렇게 된다.

• (관리자로 하여금) 메트릭을 얼마나 계측할 수 있게 하는 지에 대한 시스템의 척도
• (관리자로 하여금) 내부 상태를 파악할 수 있게 하는 시스템의 능력
• 시스템 데이터를 분석하는 접근 방식. -> 개념의 확장 정도로 받아들일 때 이건 그대로 사용할 수 있겠다.

고가용성, 안정성과 같이, 시스템이 관측 가능성을 확보하고 있다라고 표현을 한다면 관측 가능성이라는 표현이 주는 직관적인 느낌이 잘 들어맞는다.
이렇게 이해할 때, 사실 모니터링과 관측 가능성은 대립되는 개념이 절대 아니다.

모니터링이란

그럼 모니터링은 무엇인가?
시스템의 상태를 감시, 확인하는 것을 말한다.
즉, 모니터링은 어떠한 행위이며 그 행위의 주체는 운영자나 관리자, 즉 사람이다.
CPU, 메모리 사용량 등의 지표는 OS 수준에서 기본적으로 파일시스템 어딘가에 출력이 되고 있다.
이렇게 이미 시스템이 내재한 어떤 지표들을 확인하며 시스템의 상태를 확인하는 행위가 모니터링인 것이다.

두 용어의 차이

이제 비로소 주되게 거론되는 담론의 표면을 짚을 수 있게 됐다.
그럼 왜 다들 하나 같이 모니터링과 관측 가능성을 대비시키며 관측 가능성을 설명하는가?
모니터링은 관리자가 하는 행위를 일컫는 표현인 반면, 관측 가능성은 시스템이 관리자가 관측할 수 있게 각종 정보를 노출하는 속성을 나타내는 표현이다.
관측 가능성이라는 속성이 확보된 시스템에 대해서 관리자는 모니터링이란 행위로 많은 정보를 얻을 수 있다.
이렇게 표현하는 것이 맞지 않은가?

굳이 둘의 차이를 비교하는 이유

나는 이것이 현대에 들어 급작스레 대두된 관측 가능성의 필요성을 극적으로 드러내기 위한 프로파간다라고 생각한다.
그도 그럴 것이, 관측 가능성이란 용어를 실제로 정의하면서 모니터링이라는 행위가 확장될 수 있기 때문이다.

모니터링이란 용어만 있을 때, 모니터링 측면에서 시스템이란 정적인 기준을 정해두고 바라보는 관찰 대상에 불과했다.
"서버에서 500 에러를 반환하는 상황은 위험한 상황이다."
이 정도의 기준만 정해둔 채, 서버에서 출력되는 로그를 수동적으로 관찰하던 것이 기존 모니터링의 개념이었다.

관측 가능성이란 개념이 나오고 난 이후, 더 이상 모니터링은 수동적으로 머무른 채 끝나지 않는다.
분산 배치할 수록 고가용성 지표가 높아진다고 하듯, 관측 가능성은 (정량적으로 따지긴 힘들더라도) 시스템을 평가하는 하나의 척도가 된다.
관측가능성은 시스템의 내부 상태를 출력하기 위한 각종 소프트웨어를 구축하고, 메트릭을 라벨링하거나 집계할 수록 하는 등의 설정을 얹을 수록 높아진다.
"http 요청 중 200을 반환하긴 하지만 사용자 관점에서 에러인 요청들을 따로 집계해보고 싶다."
이런 희망사항을 충족하기 위해 그저 현재의 지표들로 어떻게 이를 충족할 수 있을까만 따지는 것이 아니라, 아예 서비스 로직을 수정하고 추가적인 메트릭 에이전트를 설치하거나 운영하는 식으로 능동적으로 작업을 수행해나가는 것.
이러한 운영 작업들은 궁극적으로 시스템의 관측 가능성을 높이며, 이를 통해 관리자는 더욱 효과적으로 모니터링을 할 수 있게 된다.

이것은 아무래도 어플리케이션의 분산 배치나 클라우드 컴퓨팅을 통해 멀티 환경을 활용하는 게 활발해진 현시대에 필요할 수밖에 없는 방식이다.
갈수록 시스템의 아키텍쳐는 복잡해지고 하나의 클라이언트의 요청은 내부에서 여러 트래픽을 분화되거나 꼬리물기로 늘어난다.
더 이상 과거처럼 수동적인 모니터링으로는 얻을 수 있는 정보에 한계가 있기에, 적극적으로 구축 및 운영 작업의 일환으로 관측 가능성을 확보하여 효율적으로 모니터링이 가능한 상태를 만드는 것이 중요해졌다.

결론

그래서 나는 현시대의 담론에 대해 이렇게 짧은 평을 하고자 한다.
모니터링과 관측가능성을 굳이 대비시키는 담론에는, 현대의 복잡한 시스템에서 효율적인 모니터링을 하기 위해 운영 작업(설계와 구축) 측면에서 다뤄야 하기에 시스템에서의 속성을 강조하고자 하는 의지가 반영돼있다.

관측 가능성이란 개념이 생기기 이전, 기존의 모니터링은 어떤 행위였는가?
모니터링은 현재 주어지는
모니터링은 기껏해야 주어지는 데이터를 정의한 기준과 비교하는 정도의 수동적인 행위에 불과했다.
그러나

사실 나는 사람을 헷갈리게 하는 이런 담론이 그다지 맘에 들지는 않는 것 같다.
그저 시대가 변하면서, 추가적인 수요가 생겼을 뿐이고 이에 따라 운영 방식에 변화가 생긴 것일 뿐이다.
자연스레 관리자가 생각해야 할 시스템의 속성이 추가된 것일 뿐인데 굳이 모니터링과 대비시키는 것은 혼란을 야기하지 않을까?
관측 가능성이 생겼으니 이제 모니터링하지 않기라도 할 것이란 말인가?

사실 내가 잘 이해하고 있는 것인지, 나는 아직 명확히 모른다.
일개 취준생이, 그것도 엔지니어링으로 진로를 정한 지 1년도 안 되는 내가 남들보다 이해도가 깊을 것이라 생각하지 않는다.
다만 항상 철학과에서 그러했듯이, 이해하지 못하는 것들이 있다면 넘어가지 못하는 쇠고집으로 내 나름의 고찰을 정리해볼 뿐이다.

여담

하도 이해가 안 돼서 자료를 몇 개 찾아보다가, 내 생각에 힘을 실어줄 수 있을 만한 문서를 찾았다.^[6]

There is no doubt that observability is a desirable property of a system.

내가 생각한 바를 정확하게 표현하고 있다.

observability is a measure of how well internal states of a system can be inferred from knowledge of its external outputs.

제어 이론에서의 관측 가능성 정의는 내가 생각한 정의와 정확하게 일치한다.
내 의견을 뒷받침할 자료를 찾았기에, 나는 내 정의가 정합하다는 것을 확정짓고자 한다.

관련 문서

참고

Istio 1기 - Istio Hands-on을 진행하며 공부한 내용